So, what's the logic for making a release? Change by hand the version number in pyproject.toml? Then introduce a tag matching this version number? The job then picking the tag up?

So, what's the logic for making a release? Change by hand the version number in pyproject.toml? Then introduce a tag matching this version number? The job then picking the tag up?

Yes.
I suspect you have a better suggestion?
Would be keen to hear what you think.

I use https://github.com/tschm/.config-templates/blob/main/.github/workflows/release.yml across my repos. This job can only be triggered manually. A new version number has to be explicitly provided. The workflow is then creating the tag (via git tag), and is replacing the version string in pyproject.toml (if it exists) via sed. I then build the dist artifact (using hatch). At no point I commit the changed pyproject.toml file. It has worked very well for me...

I use https://github.com/tschm/.config-templates/blob/main/.github/workflows/release.yml across my repos. This job can only be triggered manually. A new version number has to be explicitly provided. The workflow is then creating the tag (via git tag), and is replacing the version string in pyproject.toml (if it exists) via sed. I then build the dist artifact (using hatch). At no point I commit the changed pyproject.toml file. It has worked very well for me...

Hm, but that workflow does not link the GitHub release to the package release, does it? Because a GitHub release creates a tag, so the job cannot do it.

I use https://github.com/tschm/.config-templates/blob/main/.github/workflows/release.yml across my repos. This job can only be triggered manually. A new version number has to be explicitly provided. The workflow is then creating the tag (via git tag), and is replacing the version string in pyproject.toml (if it exists) via sed. I then build the dist artifact (using hatch). At no point I commit the changed pyproject.toml file. It has worked very well for me...

Hm, but that workflow does not link the GitHub release to the package release, does it? Because a GitHub release creates a tag, so the job cannot do it.

It does, the GitHub release and the PyPi release are served from the same dist folder. Here's a tiny repo where both releases take place: https://github.com/tschm/TinyCTA

so, you trigger the GH release by pushing the tag, rather than pushing the tag from GH release? I see!

In this case, I think your method is less secure, because you move the key authentication step from GitHub authentification (2-factor) to pushing a tag to main.

To make a GitHub release, you need to be logged into the GitHub service, which typically requires 2FA and is the key security audit point in GH. Whereas pushing a tag to main is a different entry point that is provably easier to compromise than full access to a GH account - since you can push a tag when having the latter (but do not necessarily need to have full account control).